In WLAN inter-working, the terminal needs to be addressable so that it can access any service it subscribed to. When the services are delivered over IP, the terminal must be attached to a certain IP address. In the mobile world, the point of attachment of the terminal changes frequently. It is highly possible that the terminal traverses a few domains during one active service session. To satisfy the requirements of terminal mobility, the address management mechanism is needed to configure and update the terminal's address every time it changes the point of attachment.
Mobile IP is an open standard, defined by the Internet Engineering Task Force (IETF) (non-patent reference 1) (non-patent reference 2), that provide a solution for the address management and traffic routing for the mobile terminals. It allows the user to remain reachable using the same address when roaming among different IP networks. Since the mobility is controlled at the IP level, it is not bound to the under lying link layer technologies. Therefore, for terminals in the 3G cellular networks, or the Wireless LAN (e.g. 802.11 networks), same protocol stack could apply. With the merging of the access technologies, e.g. the inter-working of the WLAN and 3G cellular networks, this kind of harmonized level solution is especially useful. In MobileIP, the address management is done over the IP connectivity. In case the IP connectivity is not available, it could not work. MobileIP also requires the terminal to own a Home Address, and know its Home Agent. This might not be available in the inter-working scenarios, e.g. when the terminal powers up in the foreign WLAN for the first time.
Mobile IPv6 draft has introduced a way of setting the home address of the mobile node (non-patent reference 2). The terminal would generate a care of address first, e.g. utilizing DHCPv6 (non-patent reference 3), and use this address to communicate with its home network to set up the final home address. In WLAN inter-working, this is not workable, since the mobile node's home network may not be always reachable using the care of address obtained from the WLAN. Also, the multiple round-trip configuration procedure would be time consuming, and could not meet the expectation of the users.
The Diameter Mobile IPv6 Application (non-patent reference 4) has presented a solution based on the AAA architecture for the address management for the Mobile IPv6. This solution has utilized the AAA servers and clients in the visited and home network to carry out the address updating and agent discovery. The mechanism requires the mobile node to have local IP connectivity for the message exchange, e.g. able to listen for the Router Advertisement messages, and this is not always possible due to the foreign domain's local policy. Also, the scheme only caters for the situation where the address belongs to the mobile terminal's home domain. In the WLAN inter-working, the terminal would use address from another domain depending on the service it's accessing. This could not be supported in the scheme since it has not information of the service request of the terminal. This scheme is designed for the Mobile IPv6 environment, and therefore could not work with terminals with no Mobile IP stack.
3GPP also has provided a solution, GTP (non-patent reference 5) for managing the terminal addressing and tunnelling. GTP comprises two parts, GTP-C for control and GTP-U for user data traffic. GTP runs over UDP, and encapsulates the user data in the UDP packets. The GTP is designed for the GPRS (non-patent reference 6) network, and therefore depends heavily on the GPRS network's features, e.g. GGSN, SGSN nodes. This makes it difficult to be deployed in the simple wireless access network (e.g. WLAN).    (Non-patent reference 1) “IP Mobility Support for IPv4”    www.ietf.org/rfc/rfc3344.txt    (Non-patent reference 2) “Mobility Support in IPv6”    www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txt    (Non-patent reference 3) “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”    www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-28.txt    (Non-patent reference 4) “Diameter Mobile IPv6 Application”    www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv-6-02.txt    (Non-patent reference 5) “GPRS Tunnelling Protocol (GTP) Across the Gn and Gp Interface (Release 5)” 3GPP TS 29.060 V5.3.0 (2002-09)    tp.3gpp.org/Specs/archive/29_series/    (Non-patent reference 6) “General Packet Radio Service (GPRS); Service Description; Stage 2 (Release 5)” 3GPP TS 23.060 V5.2.0 (2002-06)    ftp.3gpp.org/Specs/archive/23_series/    (Non-patent reference 7) “IP Multimedia Subsystem (IMS); Stage 2 (Release 5)” 3GPP TS 23.228 V5.6.0 (2002-09)    ftp.3gpp.org/Specs/archive/23_series/    (Non-patent reference 8) “Diameter Base Protocol”    www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt    (Non-patent reference 9) “PPP Extensible Authentication Protocol (EAP)”    www.ietf.org/rfc/rfc2284.txt    (Non-patent reference 10) 3GPP Project    www.3gpp.org    (Non-patent reference 11) 3GPP2 Project    www.3gpp2.org    (Non-patent reference 12) “The Network Access Identifier”    www.ietf.org/rfc/rfc2486.txt    (Non-patent reference 13) “Numbering, addressing and identification (Release 5)” 3GPP TS 23.003 V5.3.0 (2002-06)    ftp.3gpp.org/Sepcs/archive/23_series/    (Non-patent reference 14) “Port-Based Network Access Control” IEEE Std 802.1x-2001    standards.ieee.org/getieee802/    (Non-patent reference 15) “Diameter Extensible Authentication Protocol (EAP) Application”    www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt    (Non-patent reference 16) “Diameter NASREQ Application”    www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt    (Non-patent reference 17) “IPv6 Stateless Address Autoconfiguration”    www.ietforg/rfc/rfc2462.txt
Usually WLAN and the inter-worked network are in different administrative domains, which means their address spaces are managed separately. Therefore, when a mobile terminal roams into a WLAN in a different domain than its home network, some address configuration must be carried out to guarantee the continuous service delivery to the terminal. This address configuration could include for example IP address allocation, address registration, tunnelling set-up, etc.
For certain services delivered to the terminal over the WLAN, address restrictions would apply. For example, to access the IMS (non-patent reference 7) service in the 3G networks from the WLAN would require the terminal to own an address belonging to the network providing the IMS. Consequently, a mobile terminal with parallel access to different services would be required to have multiple IP address configured.
In WLAN, terminals are not allowed to use any resources, e.g. send or receive normal data packets, before they are authenticated, and authorized to do so. Using normal schemes, e.g. the one suggested in MIPv6, the address configuration could only happen after the successful authorization procedures. This kind of approach is slow, and is not able to meet requirements of some of the services. In order to have the address configured before the authorization, relevant information needs to be integrated into the access control messages. The address management is usually based on the user's subscription information. Therefore, it must be controlled by the mobile terminal's home network. For certain external services, the address needs to be allocated from domain other than the home network. In this case, a mechanism is required to allow the home network to negotiate the address allocation, and other information with that domain.
When a terminal changes its address, the end-to-end QoS associated to it would be affected. For example, a traffic filter based on source or destination address information would not be able to correctly classify the streams if the address changed. For a WLAN that implements firewall or other traffic control functions, the terminal's new address also needs to be signalled, otherwise traffic could be blocked or dropped.